There has been known a shared disk type cluster system that comprises both active system and standby system servers and a shared disk to prevent the system from stopping due to occurrence of a fault in a computer (for example, Patent Literature 1, Patent Literature 2 and the like). In such a shared disk type cluster system, data of a business application running on both servers is stored in a shared disk that is accessible both from the active system server and from the standby system server.
Then, when a fault occurs in the active system server, a cluster software activates the business application in the standby system server to switch the business application. The business application activated in the standby system server uses the data stored in the shared disk to resume a business processing from a point where the business application of the active system server stops.
In the shared disk type cluster system, the active system server and the standby system server respectively store data in the shared disk. As such, there is a risk that the data may be destructed when the both active system and standby system servers simultaneously write in the shared disk. Therefore, exclusive control is performed in order that writing is performed only from the active system server in normal operation.
When performing a failover in the shared disk type cluster system, the exclusive control needs to be appropriately performed to securely stop a failed server from accessing the shared disk. There are mainly the following four approaches as a method to stop access to the shared disk in the shared disk type cluster system, each of which has a problem:
i) Unmounting the Disk
Processing of unmounting a disk takes time. Further, the unmounting processing fails when there is an ongoing writing process.
ii) Closing a Port of Fiber Channel (FC) Switch
Since a server connects to a module outside the server, connection takes time. Further, depending on a type of fault, the server cannot connect to the FC switch.
iii) OS (Operating System) Panic
I/O (input/output) data that remains in a cache of a HBA (Host Bus Adapter) card may possibly be written in the shared disk. Further, even when access to the shared disk can be stopped, a failover cannot be performed in high speed since the failover is caused by the OS panic.
iv) Stopping by a BMC (Baseboard Management Controller; Onboard Server Management Chip)
In a method that the BMC forcibly resets the HBA card or blocks a power supply to the HBA card, when the BMC is busy, stopping access to the shared disk takes time, thus, the failover cannot be performed in high speed. Further, since the BMC forcibly stops the access in a timing that the OS or a driver cannot recognize the BMC, the OS panic occurs, thereby taking time for the failover. Moreover, when the BMC is inactive, the access to the shared disk is not stopped, nor occurs the failover.